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Abstract 


Technologies  developed  under  the  U.S.  Navy’s  science  and  technology  (S&T) 
umbrella  have  historically  had  only  moderate  success  transitioning  to  Navy 
Command  and  Control  (C2)  programs  of  record  (PORs).  The  primary  reason  for  the 
limited  success  rate  stems  from  the  different  missions  of  the  two  program  sponsors. 
S&T,  consisting  primarily  of  research  scientists  and  technologists,  has  a  mission  to 
“foster  and  encourage  research”  as  related  to  future  naval  power  whereas  the  C2 
Program  Office  is  focused  on  “providing  and  updating  communication  and 
information  technology  systems”  for  the  C2  of  the  maritime  forces.  This  difference  in 
mission,  with  the  corresponding  separate  funding  sources,  complicates 
communication  and  coordination  between  these  two  communities  as  each  strives  to 
achieve  its  respective  goals  and  objectives.  If  S&T  funded  programs  are  to  solve  C2 
operational  shortfalls,  there  needs  to  be  close  coordination  throughout  the  total 
acquisition  cycle  with  the  Program  Office  directly  involved  in  the  S&T  development 
program. 

In  FY  2009,  the  Office  of  Naval  Research  (ONR),  in  collaboration  with  Program 
Executive  Office  for  Command,  Control,  Communications,  Computers,  and 
Intelligence  (PEO  C4I),  initiated  a  modified  S&T  development  process  designed  to 
deliver  new  capabilities  for  the  Navy’s  Maritime  Tactical  C2  (MTC2)  POR.  This  new 
initiative  is  the  C2  Rapid  Prototyping  Continuum  (C2RPC)  and  is  jointly  funded  by 
ONR  and  PEO  C4I.  In  this  relationship,  new  technology  prototypes  are  assessed  in 
an  operational  environment  at  the  Commander  Pacific  Fleet  (COMPACFLT) 
Headquarters  in  anticipation  of  transition,  in  whole  or  in  part,  to  PEO  C4l’s  Command 
and  Control  Program  Office  (PMW  150)  for  incorporation  into  the  next  generation 
operational  C2  POR. 

C2RPC  has  streamlined  the  S&T  phases  of  the  acquisition  process,  coupling 
emerging  technology  requirements,  development,  testing,  and  integration  phases 
into  a  continuous  agile  software  development  model.  PMW  150  concurrently 
facilitated  the  early  introduction  of  the  new  capability  prototypes  to  the  Rapid 
Integration  and  Test  Environment  (RITE),  established  by  PMW  150  for  test  and 
evaluation  of  maritime  C2  software.  RITE  has  an  established  information  repository 
which  allows  prototype  developers  to  share  a  common  development  infrastructure 
and  to  communicate  and  collaborate  directly  with  POR  test  and  integration 
engineers.  By  engaging  with  the  POR  early  in  the  prototype  demonstration  phase, 
the  selected  capabilities  are  well  positioned  for  successful  transition  as  they  reach 
the  requisite  technology  readiness  levels  (TRLs)  needed  for  full  development. 
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This  paper  presents  the  C2RPC  development  and  transition  processes,  using  a  rapid 
incremental  development  model  that  aligns  with  the  new  information  technology  (IT) 
acquisition  cycle  and  bridges  the  software  transition  valley  of  death.  It  presents  early 
prototype  experimentation  and  demonstration  results  and  provides  a  projection  of 
remaining  activities  planned  to  meet  the  next  generation  of  maritime  C2. 

Introduction 

PMW  150  has  embarked  on  a  new  strategic  initiative  focused  on  dramatically 
enhancing  the  functional  capabilities  of  the  Navy’s  maritime  C2  systems  while  fundamentally 
changing  its  software  acquisition  processes.  New  processes  are  needed  to  meet  rapidly 
changing  operational  requirements  and  to  take  advantage  of  new  technology 
enhancements.  These  processes  use  an  evolutionary  approach  to  deliver  an  accelerated 
development  cycle  while  achieving  cost  reductions  through  programmatic  efficiencies  and 
the  elimination  of  redundant  processes.  The  C2RPC  is  delivering  on  the  strategic  initiative 
by  providing  new  technology  prototype  development  for  the  C2  POR. 

C2RPC  Implementation 

The  Command  and  Control  Rapid  Prototyping  Continuum  (C2RPC)  combines 
emerging  science  and  technology  (S&T)  development,  advanced  prototypes,  and 
experimentation  processes  to  employ  new  maritime  C2  capabilities.  The  C2RPC  serves  as 
an  incubator  for  technology  and  “proofs  of  concept”  to  produce  capabilities  that  can  be 
transitioned  into  future  Command  and  Control  (C2)  programs  of  record  (PORs). 
Development  of  the  C2RPC  follows  the  “build  a  little — test  a  little”  philosophy,  employing  a 
series  of  incremental  capability  “drops”  to  demonstrate  the  prototypes  and  gain  user 
feedback.  The  first  capability  drop  (Drop  1)  was  implemented  at  COMPACFLT  in  March 
2010.  Drop  2,  and  each  successive  drop,  builds  upon  existing  capabilities  to  provide 
additional  C2  functionality.  The  C2RPC  process  allows  for 


■  rapid  and  continual  technology  insertion  (e.g.,  continuous  integration); 

■  continuous  prototype  development  and  experimentation  cycle; 

■  development  of  individual  smaller  development  components/increments, 
therefore  reducing  overall  C2  program  risk;  and 

■  closer  alignment  of  S&T  investment  to  POR  requirements,  increasing  the 
probability  of  successful  transition. 


Navy  Command  and  Control  Strategy 

The  U.S.  Navy  is  undergoing  a  major  IT  transformation  to  meet  changes  in  its 
operational  commitments  and  to  ensure  that  necessary  operational  and  intelligence 
information  is  delivered  to  the  “right  person,  at  the  right  time,  and  in  the  right  way.” 
Historically,  Navy  C2  systems  have  simply  provided  “who  and  where”  information  to  battle 
commanders’  situational  awareness.  Future  C2  systems  need  to  fulfill  Operational  Level  of 
War  (OLW)  requirements,  and  will  be  required  to  provide  timely  what,  when,  why  and  how 
information,  in  addition  to  who  and  where.  This  new  C2  strategy  is  codified  in  the  Naval 
Warfare  Publication  3-32  on  “Maritime  Operations  at  the  Operational  Level  of  War  (OLW)” 
(DoN,  2008)  and  the  Navy  Planning,  Naval  Warfare  Publication  (NWP)  5-01  (DoN,  2007). 
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Four  Functional  Pillars 

PMW  150’s  maritime  C2  strategy  developmental  roadmap  is  built  around  the  four 
functional  pillars  of  C2  Mission  Management  as  shown  in  Figure  1 .  The  four  pillars  are 
Planning,  Execution,  and  Assessment;  Intelligence  and  Collection  Management; 

Intelligence,  Surveillance  and  Reconnaissance  (ISR)  Data  Fusion;  and  Force,  Unit,  Network 
Capabilities  and  Readiness. 

A  representative  example  of  the  initial  capabilities  that  are  being  developed  by 
C2RPC  in  support  of  these  four  pillars  is  also  shown  in  Figure  1 .  There  is  an  additional 
“invisible”  pillar  in  the  C2RPC’s  approach.  This  invisible  pillar  is  User  Facing  Services  (UFS) 
and  it  is  depicted  by  the  center  of  the  figure.  This  is  where  the  majority  of  the  C2RPC  user 
interactions  are  performed.  It  is  important  to  note  that  PMW  150  is  only  responsible  for 
providing  the  functionality  associated  with  the  Planning,  Execution,  and  Assessment  Pillar 
and  the  User  Facing  Services.  Therefore,  PMW  150  must  rely  on  external  organizations  for 
the  services  and  database  repositories  that  are  resident  within  their  respective  pillars. 
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Figure  1.  Functional  Pillars  of  C2  Mission  Management 
C2RPC  Incremental  Functionality 

PMW  150  has  adopted  a  component  portfolio  approach  to  C2  system  software 
acquisition.  Incremental  development  is  a  key  element  of  PMW  150’s  system  software 
component  strategy  and  requires  close  collaboration  among  developers,  evaluators,  and 
end  users  (warfighters).  Each  component  of  capability  provides  a  militarily  useful  and 
supportable  operational  capability.  These  components  are  iterated  over  time  and  delivered 
when  mature.  The  system’s  architecture  is  designed  to  support  these  incremental  deliveries 
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and  enables  additional  components,  or  higher-performing  implementations  of  existing 
components,  to  be  added  periodically  to  the  core  Navy  C2  architecture. 

Initial  Operational  Capability 

The  focus  of  the  initial  C2RPC  prototype  was  in  support  of  the  Fleet’s  ability  to 
conduct  high-priority  missions  and  plans  within  the  COMPACFLT  area  of  responsibility 
(AOR).  Figure  2  depicts  the  initial  capabilities  that  are  projected  for  MTC  2  Release  One. 

The  figure  includes  a  core,  or  “central  capability”  (Applications  Support,  Data 
Management  and  Enterprise  Services  abstraction),  that  C2  components  will  be  integrated 
into  and  interact  with.  These  core  capabilities  are  shown  in  the  bottom  set  of  boxes  in 
Figure  2.  The  additional  capabilities  align  with  the  four  functional  pillars  discussed 
previously  and  are  shown  in  the  color-coded  boxes.  There  may  be  unfamiliar  acronyms 
shown,  but  the  specific  functional  definition  is  less  important  for  the  purposes  of  this  paper 
than  the  methods  used  for  rapid  development  and  demonstration.  This  phased  delivery  is 
designed  to  add  increased  overall  C2  functionality  with  each  successive  drop  achieving  a 
new  objective  (e.g.,  Readiness  and  Maritime  Operations  Centers  (MOC)  established  in  Drop 
2  will  be  Enhanced  in  Drop  3).  The  successive  drops  are  additive  and  the  proven,  operator- 
validated  capabilities  from  the  collective  set  will  represent  the  C2  capabilities  carried  forward 
as  MTC2  Release  One.  In  all,  there  are  four  drops  planned  before  the  “capability  cut-off’ 
later  this  year.  At  that  time,  the  aggregate  release  set  of  capabilities  will  transition  to  POR 
funding  and  go  through  additional  hardening  and  developmental  testing  (i.e.  unit,  regression, 
etc.)  before  entering  a  formal  Development  Test  and  Operational  Test  (DT/OT)  program.  It 
is  important  to  note  that  individual  components,  although  based  upon  an  initial  set  of 
capability  objectives,  are  dynamic.  The  final  component  functionality  is  a  product  of  the 
baseline  warfighter  objectives  and  modifications  approved  as  a  result  of  the  prototyping 
process  and  direct  feedback  from  operational  users. 
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Figure  2.  MTC2  Release  One 
Prototyping  Continuum 

Under  the  C2RPC  initiative,  the  development  and  maturing  of  new  technology  is 
ongoing  and  will  continue  using  additional  S&T  funding  after  the  capability  cut-off  for 
Release  One.  Figure  3  represents  a  listing  of  potential  C2RPC  capabilities  proposed  for 
future  prototype  development.  Again,  the  specific  components  and  their  respective 
acronyms  are  not  as  important  as  the  method  used  to  continually  address  new  technology 
development  for  achieving  additional  C2  functional  objectives.  In  the  future  drops,  the 
objective  is  to  support  operational  units  expanding  from  the  ashore  MOCs  to  the  afloat  Navy 
(e.g.,  task  force,  TF,  and  task  group,  TG,  level  ships).  The  final  set  selected  for  MTC2 
Release  Two  will  be  derived  from  the  continually  evolving  set  of  mission-oriented 
requirements  and  maturing  prototypes. 
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Figure  3.  Proposed  Navy  Planning,  Execution,  and  Assessment  Services 

C2RPC  Prototype  Development  and  Experimentation  Methodology 

The  C2RPC  team  is  comprised  of  “thought-leaders”  in  situational  awareness,  navy 
planning  and  assessment,  Fleet  readiness,  and  MOC  operations.  This  collection  of  experts 
is  paired  with  subject  matter  experts  (SMEs)  in  C2  systems  development  and  together  they 
work  closely  with  Fleet  representatives  to  demonstrate  rapid  technology  prototypes  and 
gather  operational  feedback.  This  working  relationship  has  led  to  enhanced  C2  functionality 
in  the  early  prototypes.  This  section  will  present  the  methodology  employed  by  the  C2RPC 
to  develop,  mature,  and  transition  C2  components  in  an  incremental  and  continuous 
development  approach. 

National  Defense  Authorization  Act  of  2010  Alignment 

In  2010  Congress  passed,  and  the  President  signed,  the  National  Defense 
Authorization  Act,  becoming  Public  Law  1 11-84.  This  law  defined  a  new  acquisition  process 
for  IT  systems.  Conventional  DoD  acquisition  processes  are  too  long  and  cumbersome  to  fit 
the  needs  of  IT  systems  that  require  near  continuous  change.  This  new  process  is  to  be 
based  upon  the  recommendations  provided  in  the  March  2009  Report  of  the  Defense 
Science  Board  (DSB)  Task  Force  on  Department  of  Defense  Policies  and  Procedures  for 
the  Acquisition  of  Information  Technology  (hereafter  referred  to  as  DSB-IT;  USD[AT&L], 
2009). 

The  DSB-IT  recommendation  was  for  a  new  acquisition  process  for  IT,  as  shown  in 
Figure  4. 
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Figure  4.  DSB-IT  Recommended  Acquisition  Process  for  Information  Technology 

The  process  shown  is  geared  toward  delivering  meaningful  increments  of  capability 
in  approximately  18  months  or  less,  and  it  leverages  the  advantages  of  modern  IT  practices. 
Multiple,  rapidly  executed  releases  of  capability  allow  requirements  to  be  prioritized  based 
on  need  and  technical  readiness,  allow  early  operational  release  of  capability,  and  offer  the 
ability  to  adapt  and  accommodate  changes  driven  by  field  experience.  The  new  process  will 
include 


■  early  and  continual  involvement  of  the  user; 

■  multiple,  rapidly  executed  increments  or  releases  of  capability; 

■  early,  successive  prototyping  to  support  an  evolutionary  approach;  and 

■  a  modular,  open-systems  approach. 

The  C2RPC  methodology  has  all  of  these  attributes  and  is  described  in  this  section. 

C2RPC  Implementation  Roadmap 

A  notional  C2RPC  implementation  roadmap  with  its  various  programmatic  stages  is 
shown  in  Figure  5.  The  graphic  shows  the  relationships  between  the  stages,  including  the 
planned  transition  of  new  C2RPC  technologies  to  the  MTC2  POR  after  completing  “Early” 
and  “Late”  Stage  prototype  development  cycles.  The  roadmap  aligns  with  both  traditional 
DoD  Acquisition  Life  Cycle  milestones  required  in  DoD  Instruction  5000.02  (USD[AT&L], 
2008)  and  the  processes  recommended  in  the  DSB-IT. 
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Figure  5.  Notional  C2RPC  Implementation  Roadmap 

C2RPC  Capability  Requirements  Definition 

C2RPC  employs  a  modified  approach  for  the  identification  and  assessment  of  C2 
capability  objectives.  A  C2  independent  product  team  (C2IPT)  consisting  of  SMEs  from 
ONR,  working  along  with  PMW  150  and  COMPACFLT,  meet  in  periodic  workshops  at 
COMPACFLT  Headquarters  to  identify  and  prioritize  operationally  relevant  C2  objectives. 
These  2-3  day  forums  are  held  every  3-6  months  and  normally  coincide  with  increment 
drops,  so  that  the  users  have  the  opportunity  to  express  their  ideas  and  provide  input  to  the 
software  developers  directly.  The  workshops  are  chaired  by  ONR  but  include 
representatives  from  all  stakeholders. 

At  the  initial  workshop,  held  June  24-26,  2008,  the  first  set  of  development 
objectives  was  established  in  response  to  COMPACFLT  priorities.  These  included  the 
following: 

■  C2  of  Intelligence  Operations, 

■  C2  of  Information  Operations, 

■  C2  of  Network  Operations, 

■  C2  of  Computer  Network  Protection,  and 

■  Common  Operational  Picture  (COP)  Improvement. 

These  agreed  objectives  were  used  to  derive  a  set  of  “capability  gaps”  that  were  prioritized 
for  the  initial  C2RPC  C2  increment.  The  capabilities  have  since  evolved  and  new 
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capabilities  have  been  added  as  a  result  of  experimentation  and  early  exposure  to  the 
operator  who  provided  recommended  modifications. 

To  support  the  requirements  definition,  the  roadmap,  shown  in  Figure  5,  lists  several 
requirements  related  documents  that  are  important  to  the  establishment  of  an  upfront 
Technology  Development  Strategy,  and  are  necessary  to  achieve  acquisition  Milestones 
and  Build  Decisions  for  MTC2.  These  documents  include  the  following: 

■  Initial  Capabilities  Document  (ICD).  As  described  in  the  Joint  Capacities 
Integration  and  Development  System  (JCIDS)  manual  (CJCS,  2009),  the  ICD 
documents  the  “need  for  a  materiel  approach,  or  an  approach  that  is  a 
combination  of  materiel  and  non-materiel,  to  satisfy  specific  capability 
gap(s).”  The  ICD  defines  the  gap  in  terms  of  functional  area;  relevant  range 
of  military  operations;  desired  effects;  time  and  Doctrine,  Organization, 
Training,  Materiel,  Leadership  and  Education,  Personnel,  and  Facilities 
(DOTMLPF);  and  policy  implications  and  constraints.  The  outcome  of  an 
ICD  could  result  in  one  or  more  DOTMLPF  Change  Recommendations 
(DCRs)  or  Capability  Development  Documents  (CDD). 

■  Capabilities  Development  Document  (CDD).  The  Technology  Development 
Strategy  includes  a  description  of  how  the  materiel  solution  is  sub-divided  into 
Capability  Increments,  Releases,  and  Iterations  (drops).  The  CDD  builds  on 
the  ICD  and  provides  detailed  operational  performance  parameters 
necessary  to  complete  the  proposed  systems  design.  These  requirements 
are  prioritized  and  parsed  into  groupings  to  establish  baselines  for  initial  and 
subsequent  releases.  The  objective  of  C2RPC  is  to  develop  and  deploy  the 
highest  priority  mission  capability  first  and  reduce  the  technical  risk  to  the 
POR.  Therefore,  capabilities  defined  in  the  CDD  are  prioritized  and,  where 
appropriate,  grouped  into  a  limited  number  of  time-phased  releases  that 
correspond  to  mission  priorities.  An  agile  approach  allows  for  the 
reprioritization  of  requirements  for  each  iteration  and  release  (and  for  the 
increment  as  a  whole)  based  on  subsets  of  functionality  to  prevent  delay  and 
facilitate  rapid  development  and  deployment. 

■  Capabilities  Development  Plan  (CDP) — Release  1  to  Release  (n).  The 
purpose  of  the  Capability  Development  Plan  (CDP)  is  to  serve  as  the 
agreement  between  the  Program  Sponsor,  the  Program/Project  Manager 
(PM),  and  the  Acquisition  Decision  Authority  (ADA)  on  the  activities,  cost, 
schedule,  and  performance  boundaries  of  the  work  to  be  performed  for  the 
POR  and  the  artifacts  from  C2RPC  are  used  to  substantiate  the  reduced  risk. 
The  CDP  presents  topics  and  issues,  specific  to  the  acquisition,  that  allow  the 
PM  to  clearly  define  the  “body  of  work”  that  must  be  accomplished  during 
each  planned  software  release. 

Continuous  Prototype  Development 

C2RPC  has  separated  prototype  development  into  two  distinct  stages:  Early  Stage 
and  Late  Stage.  These  stages  are  related  to  overall  technology  maturity  levels  of  the 
respective  capability  components  and  have  separate  S&T  funding  sources.  The  Early 
Stage,  designated  for  Advanced  Technology  Development,  is  funded  by  6.2  and  6.3 
budgets,  while  the  Late  Stage,  involving  Demonstration  and  Validation  experiments  (along 
with  approved  prototype  modifications  and  changes)  conducted  at  COMPACFLT,  is  funded 
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from  6.3  and  6.4  budgets.  It  is  important  to  note  that  this  separation  of  stages  supports  the 
continual  progression  of  maturing  capabilities  that  are  available  for  graduation  to  the  next 
level  of  development  without  unnecessary  delay.  For  example,  Early  Stage  capabilities  that 
have  reached  an  acceptable  technology  readiness  level  (TRL),  as  described  in  the  Defense 
Acquisition  Guide  {DAG,  n.d.)  are  moved  to  the  Late  Stage  where  they  undergo  relevant 
operational  experimentation. 

Additionally,  as  Late  Stage  capabilities  are  evaluated  at  the  requisite  maturity  level, 
they  enter  the  transition  phase,  where  they  receive  further  capability  enhancements  and  the 
software  hardening  necessary  for  final  transition  to  the  POR.  Lastly,  this  separation  of 
development  stages  allows  the  Early  Stage  to  serve  as  the  incubator  of  new  technology  with 
new  prototype  components  being  initiated  as  additional  requirements  are  identified.  The 
capability  components  need  not  adhere  to  p re-determined  development  cycles  and 
independently  move  through  the  development  process.  This  methodology  allows  the 
C2RPC  to  provide  a  “continuum”  of  new  capability  components  that  are  being  routinely 
evaluated  for  transition  to  the  POR. 

Figure  6  depicts  the  different  TRLs  and  indicates  the  separation  of  C2RPC  and  POR 
responsibilities,  including  the  overlapping  transition  of  S&T  to  POR.  The  figure  also 
introduces  the  “progressive”  integration  approach  being  employed  by  the  C2RPC  to 
gradually  introduce  POR  engineering  processes  to  the  various  release  components  as  they 
progress  from  Early-to-Late-to-Transition  Stages.  Early  prototype  development  is  often  less 
structured  and  therefore  the  prototype,  as  part  of  the  experimentation  and  maturing  process, 
needs  to  incorporate  POR  best  practices  for  items  such  as  software  configuration 
management  and  documentation.  Using  a  wiki  for  content  management,  the  development 
of  selected  documentation  is  developed  over  time  by  the  various  members  of  the  C2RPC 
team.  The  process  for  this  progressive  integration  is  covered  in  the  transition  section  later  in 
this  paper. 
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Figure  6.  C2RPC  and  Technology  Readiness  Levels  (TRLs) 

Hosted  Centralized  Repository 

The  C2RPC  hosts  a  software  development  and  transition  environment  to  facilitate 
continuous  development  and  integration.  The  hosted  environment  is  centered  on  an 
information  repository  (IR),  where  all  stakeholders  share  information  and  have  access  to  a 
common  set  of  documentation  and  development  tools.  This  hosted  environment  includes  a 
segmented  build  environment  for  each  developer  to  control  its  individual  source  code,  but 
allows  third  party  (public,  with  limited  access)  sharing  of  libraries  and  associated  tools  that 
are  used  across  multiple  developmental  projects.  The  repository  allows  a  broader 
stakeholder  base  to  interact  with  the  components  as  they  progress  through  the  various 
development  and  transition  stages.  The  services  and  support  that  are  provided  through  the 
hosted  environment  include 
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■  Developer  Version  Control, 

■  Communication  /  Tool  Support, 

■  Quality  Control,  and 

■  Automated  Testing  and  Integration  Environment. 


As  shown  in  Figure  7,  the  Central  Repository  is  actually  a  collection  of  three  types  of 
repositories.  The  cardinality  of  each  repository  type  varies,  but  in  the  figure  they  are  each 
represented  as  if  they  are  single  units.  Each  Repository  can  potentially  be  accessed  by  the 
various  stakeholders  (Developers,  Testers,  and  End-Users)  using  a  central  configuration 
management  system.  The  three  Repositories  include: 


■  Application  (Prototype  Developer)  Repositories.  Each  prototype  development 
contractor  has  access  to  its  own  repository  for  developing  source  code. 

These  modules  can  either  be  standalone  applications,  components  of  a 
parent  application,  or  code  libraries  meant  for  use  by  other  products.  By 
combining  these  modules  with  shared  code  and  external  tools  and  applying  a 
build  process  to  them,  software  configuration  items  (Cl)  can  be  produced  for 
C2RPC  use. 

■  External  Repository.  The  external  repository  is  a  public,  read-only  Subversion 
repository  for  use  by  all  participating  developers.  Its  purpose  is  to  contain 
software  CIs  that  meet  the  following  criteria: 

o  They  are  required  for  a  developer  to  create  a  software  product, 
o  They  are  publicly  available  and  free  to  use  (no  proprietary  tools  are 
allowed). 

o  They  are  not  tied  to  a  particular  developer’s  project. 

Items  that  would  be  found  in  this  repository  include: 

o  Compilers  and  interpreters  (JDK,  gcc,  Python,  Perl,  et  al), 
o  Build  tools  and  frameworks  (ant,  Maven,  ivy,  et  al), 
o  Integrated  Development  Environments  (IDEs;  Netbeans,  Eclipse,  et 
al),  and 

o  External  application  programming  interfaces  (APIs)  and  libraries. 

The  external  repository’s  primary  role  is  to  store  all  of  the  third  party  tools 
needed  by  developers  to  assemble  and  make  ready  their  development 
environment.  Because  this  repository  is  read-only,  developers  are  not  able  to 
populate  it  themselves.  In  order  to  get  the  necessary  tools,  they  must  send  a 
request  to  the  repository  configuration  management  (CM)  team,  who  works 
with  the  developers  to  place  all  needed  tools  into  the  repository.  This  is 
important  because  the  CM  team  will  be  responsible  for  using  the  developer’s 
build  instructions  to  exactly  replicate  the  software  for  testing  and  eventual 
release. 

■  Common  Component  Repository.  The  common  component  repository  is  a 
public,  limited-access  Subversion  repository  which  contains  libraries  to  be 
used  across  multiple  developer  projects.  The  typical  example  would  be  a 
repository  containing  common  interfaces  and  base  functionality  to  be  used 
across  a  set  of  software  products.  The  common  repository,  however,  is 
populated  by  code  written  by  the  developers  and  not  by  external  interfaces 
(thus  differentiating  it  from  the  code  in  the  external  repository). 
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Figure  7.  Repository  Management,  Prototype  Development  and  Transition 
C2RPC  Governance 

The  pace  of  technology  change  and  the  increasing  levels  of  complexity  in  C2 
systems  necessitate  a  more  agile  governance  model  for  the  acquisition  of  IT-intensive 
systems.  One  of  the  C2RPC’s  goals  was  to  enhance  the  project  agility  and  responsiveness 
to  technological  change  and  user  requirements.  The  C2RPC  wanted  to  establish  a  process 
where  the  Combatant  Command  (warfighter)  had  authority  to  reprioritize,  add  or  delete  non¬ 
key  performance  parameter  requirements  working  along  with  the  POR  program  sponsor  and 
appropriate  milestone  decision  authority.  This  new  governance  model  would  allow  the 
development  programs  to  more  rapidly  evolve  to  support  changing  Fleet  needs.  C2RPC 
governance  includes  several  different  activities  to  ensure  that  Fleet  inputs  are  addressed 
when  making  programmatic  changes. 

■  Periodic  Workshops.  As  stated  previously,  the  C2RPC  conducts  periodic 
workshops  to  develop  and  validate  new  C2  capability  requirements  and  to 
gather  operator  feedback  on  recent  capability  installations.  The  workshops 
are  2-3  day  forums  and  are  normally  conducted  every  3-6  months, 
coinciding  with  engineer  drops.  The  workshops  are  chaired  by  ONR  but 
include  members  of  the  C2  IPT.  These  workshops  have  been  instrumental  in 
establishing  the  operational  objectives  for  the  incremental  development  and 
related  engineering  drops.  Feedback  from  each  successive  drop  has  been 
used  by  the  development  to  further  enhance  the  C2  capabilities  being 
installed. 
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■  On-site  Technical  Representative.  Coinciding  with  C2RPC  Drop  1,  ONR 
assigned  a  C2RPC  system  engineer  to  work  on-site  at  COMPACFLT.  The 
C2RPC  system  engineer  works  with  the  operators,  trains  them  on  C2RPC, 
gathers  additional  user  feedback  and  interests,  and  helps  interpret  the 
operators’  new  capability  requests  for  C2RPC  deliveries.  This  individual 
interacts  with  COMPACFLT’s  operational  and  technical  personnel  to 
document  and  report  recommended  component  changes  to  the  developer 
team.  In  some  cases,  software  modifications  have  been  done  in  near-real 
time  and  the  operator  was  able  to  experience  the  rapid  response  to  proposed 
system  changes.  This  has  helped  to  foster  a  strong  working  relationship 
between  the  developers  and  operators  and  has  reinforced  the  operators’ 
involvement  in  the  development  process.  The  operators  are  actively 
engaged  in  providing  feedback  and  are  committed  to  the  success  of  the  final 
set  of  C2  components.  This  feedback  has  resulted  in  multiple  iterative 
improvements  to  upcoming  drops,  with  minor  updates  occurring  daily  or 
weekly. 

■  Software  Change  Requests.  In  addition  to  the  periodic  workshop  and  on-site 
technical  representation,  the  C2RPC  uses  an  online  Software  Bug  Report 
and  change  request  tool  (the  “JIRA”  system)  to  submit  change 
recommendations.  A  change  request  is  a  standard  form  for  documenting 
what  needs  to  be  accomplished,  but  does  not  address  how  the  change 
should  be  implemented.  The  JIRA  “tickets”  are  used,  in  addition  to  the 
feedback  received  via  the  other  methods,  by  the  Engineering  Review  Board 
(ERB)  to  document  longer  range  enhancements,  re-prioritize,  and  to  assign 
resources  to  the  modifications  or  requested  new  capabilities. 

■  Engineering  Review  Board.  The  Engineering  Review  Board  (ERB)  is 
responsible  for  establishing  the  technical  roadmap  for  the  C2RPC  as  well  as 
for  setting  the  capability  iteration  cycle  (drops),  prioritizing  the  capabilities  and 
fixes,  and  assigning  technical  resources  within  the  constraints  handed  down 
by  management  for  the  C2RPC.  Additionally,  it  is  responsible  for  ensuring 
the  configuration  control  of  the  various  software  increment  releases  and 
ultimately  determines  the  selection  and  timing  of  the  components  for 
migration  from  Early  Stage  to  Late  Stage  to  nominating  technologies  for 
transition.  Proposed  change  to  the  C2RPC  drops  gathered  either  through 
the  workshops  or  the  SCR  process  is  reviewed  by  the  ERB.  This  board  is 
chaired  by  the  C2RPC  Chief  Engineer  (as  designated  by  ONR  and  PMW 
150)  and  includes  representatives  from  each  of  the  four  functional  pillars 
(ISR,  etc.)  described  earlier.  The  ERB  provides  the  C2RPC  a  level  of  project 
flexibility  needed  to  meet  the  relatively  short  development  cycle.  It  is 
necessary  to  have  a  board  with  this  responsibility  and  authority  if  the  rapid 
prototyping  and  integration  activities  are  to  meet  the  4-6  month  release 
cycles  envisioned  as  part  of  the  IT-intensive  systems  acquisition  process. 

The  ERB  is  empowered  to 

o  establish  capability  requirements  and  prioritization, 
o  approve  proposed  component  changes  submitted  through  SCR 
process, 

o  modify  prototype  requirements  to  meet  operator  needs,  and 
o  select  the  mature  capabilities  and  propose  them  for  transition. 
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C2RPC  Transition  Process 


As  stated  previously,  a  significant  challenge  facing  the  C2RPC  effort  is  transitioning 
the  technology  prototype  components  to  the  MTC2  program.  The  transition  involves  the 
continued  maturation  and  hardening  of  the  final  designated  capability  components  within 
Release  One  while  undergoing  a  change  in  program  funding  from  S&T  to  POR.  This  “hand- 
off’  is  conducted  in  the  proverbial  “valley  of  death”  for  new  development  programs  where  the 
“initial  funding”  is  often  fully  expended  before  funding  needed  for  continuity  of  operation  is 
received.  In  this  situation,  it  is  more  about  management  of  the  transition  process  and  the 
close  coordination  needed  between  the  two  program  sponsors  to  avoid  any  loss  of 
momentum  as  the  capability  components  are  transitioned.  There  need  to  be  shared 
expectations  and  appropriate  funding  levels  provided  by  the  respective  sponsors.  It  is 
critical  during  this  transition  phase  that  the  S&T  funded  prototypes  achieve  the  expected 
maturity  level  planned  for  by  the  MTC2  sponsor  prior  to  entering  the  transition  phase. 
Conversely,  the  Program  Office  needs  to  have  established  the  necessary  program  plan, 
schedule,  and  funding  needed  to  complete  the  software  development,  testing,  integration, 
and  ultimate  fielding.  This  program  plan  is  generated  based,  in  a  large  part,  upon  a  specific 
set  of  assumptions  and  risks  and  the  expected  transition  readiness  of  the  C2RPC 
technology.  If  the  C2RPC  capabilities  do  not  meet  the  minimum  expected,  the  transition 
could  fail,  leaving  the  MTC2  program  in  jeopardy. 

Currently  the  C2RPC  has  a  Technology  Transition  Plan  (TTP)  Level  A  with  the 
MTC2  POR  and  a  start  date  of  2013.  The  initial  C2RPC  drop  was  developed  in 
approximately  18  months.  Further  drops  are  planned  at  approximately  four  to  six  month 
intervals  until  FY  2012.  The  transition  from  the  Late  Stage  development  to  the  MTC2  POR 
for  selected  capability  components  is  scheduled  to  begin  in  early  2012  and  will  be  done  in 
various  steps.  The  transitional  activities  will  be  under  the  leadership  of  PMW  150  supported 
by  SSC  Pacific  as  part  of  its  Navy  C2  Software  Support  Activity  (SSA)  functions  and  will 
employ  testing  and  integration  processes  established  as  part  of  the  Rapid  Integration  and 
Test  Environment  (RITE)  initiative. 

Trusted  Agent  and  Software  Support  Activity  (SSA)  Roles 

SSC  PAC  supports  PMW  150  as  both  the  Navy  C2  Trusted  Agent  and  its  Software 
Support  Activity  (SSA).  These  roles  establish  SSC  PAC  as  a  key  participant  in  the  overall 
C2  acquisition  process.  The  functions  performed  by  these  two  related  roles  are  highlighted 
in  Table  1. 
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Table  1. 


SSC  Pacific  C2  Support  Roles 


Architecture  Definition 

Translating  Requirements  into  Design 

Objectives 

Engineering  Support 

Technical  Reviews 

Risk  Management 

Implementation  of  Transition  Plan 

Configuration  Management 

Deployment  Planning 

Schedules 

Sustainment 

Test  and  Evaluation 


Logging,  tracking  and  analyzing 
Modification  Requests  (MRs)  and  Problem 
Reports  (PRs) 

Replication  or  verification  of  a  reported 
problem,  as  required  as  part  of  the  PR 
analysis 

Development  of  options  for  implementing 
modifications 

Design,  development  and  testing  of 
software  enhancements 
Design,  development  and  testing  of 
software  corrections 
Provision  of  Technical  Assistance 
Provision  of  Fleet  Engineering  Support 
Provision  of  Maintenance  Support 
Performance  of  Software  Support  Risk 
Management 

Performance  of  Configuration  Management 
Development  of  Technical  Documentation 
Acquisition  and  Reporting  of  Metrics 


Rapid  Integration  and  Test  Environment  (RITE)  for  Continuous  Integration 

The  iterative  nature  of  incremental  component  software  development  and  the 
migration  to  net-centric  operations  requires  a  different  set  of  software  acquisition  processes. 
PMW  150  established  the  Rapid  Integration  and  Test  Environment  (RITE)  to  facilitate 
needed  C2  testing  and  integration  process  change.  RITE  places  increased  emphasis  on 
early  and  frequent  software  testing,  as  well  as  on  necessary  software  engineering  practices 
at  the  source  code  level.  RITE  provides  an  agile  approach  to  software  development,  taking 
full  advantage  of  technological  advances  and  open  source  models  to  automate  processes 
and  shorten  development  cycles — thus  increasing  the  maintainability  of  software  baselines. 
RITE  also  clarifies  software  delivery  requirements,  adding  engineering  structure  to  final 
deliverables  and  reducing  opportunity  for  misunderstanding  between  sponsors,  end-users, 
and  developers. 

From  the  C2RPC,  transition  and  integration  of  new,  adapted,  and  adopted  C2 
system  software  capabilities  will  be  synchronized  into  periodic  C2  Releases  (C2R), 
nominally  on  a  six-month  cycle.  The  transition  of  MTC2  Release  One  is  expected  later  this 
year  and  at  that  time  it  will  enter  the  RITE  process.  As  the  various  incrementally  developed 
capabilities  reach  the  requisite  maturity  level  (TRL  6-7),  they  will  individually  be  evaluated 
and  assessed  for  integration  into  the  POR. 
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Figure  8.  RITE  Transition  Processes  for  C2RPC  Components 

The  successful  transition  of  increments  developed  under  the  C2RPC  umbrella  is 
critical  to  achieving  rapid  Navy  C2  system  enhancement.  Therefore,  close  coordination 
between  the  POR  SSA  and  the  individual  prototype  developers  as  the  mature  capabilities 
near  transition  is  paramount.  During  the  transition,  the  development  program  must  begin 
adopting  and  implementing  the  software-development  processes  employed  by  the  POR 
while  it  is  effectively  changing  funding  sources  from  S&T  (6.3A,  6.3B)  to  POR  acquisition 
(6. 4-6. 5).  The  RITE  processes  and  infrastructure,  as  shown  in  Figure  8,  will  be  used  for  the 
transition  of  the  C2RPC.  Using  the  centralized  repository,  as  the  selected  capability 
increments  reach  the  requisite  TRL  for  transition,  they  will  enter  the  RITE’s  testing  and 
integration  processes.  These  processes  include  completion  of  a  pre-delivery  qualification 
conducted  by  the  vendor  to  ensure  that  the  prototype  is  ready  to  enter  a  set  of  iterative 
testing  and  integration  processes.  Feedback  is  provided  to  the  developer  after  each  iteration 
so  that  issues  can  be  corrected  in  a  timely  manner. 

RITE  Acceptance  Process 

Table  2  details  the  software-acceptance  process  required  to  enter  the  new 
technology  product  into  the  transition  process.  The  process  is  part  of  the  Maritime  Global 
Command  and  Control,  Family  of  Systems  (MGF)  Acceptance  and  Delivery  Process  and 
has  been  adapted  for  use  in  the  C2RPC  transition  stage.  RITE  team  members  evaluate 
software  work  product  deliveries  to  determine  their  suitability  for  integration  into  the  POR. 
The  objective  is  to  ensure  that  developers  delivering  prototype  source  code,  and  other 
software  products,  for  entry  into  the  RITE  do  not  have  obvious  or  critical  errors  or  omissions. 
The  RITE  acceptance  and  test  team  will  work  with  the  developer  to  correct  any  problems  as 
part  of  the  transition  process. 
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Table  2.  Prototype  Software  Transition  Acceptance  Process 


Step 

Actions 

Decisions  (Accept/Reject) 

1 

Developer  delivers  required  software 
work  product  and  other  deliverables  to 
RITE  Configuration  Manager.  The 
Developer  should  follow  the  prescribed 
Delivery  Qualification  Checklist. 

2 

Configuration  Manager  reviews  delivery 
package  against  Acceptance  Checklists. 
The  acceptance  checklists  include  the 
need  for  Information  Security  checks 
required  by  the  relevant  STIGs. 

•  Accept;  notify  Quality  Engineering  (QE) 
to  conduct  baseline  “as  is”  assessment. 
(NOTE:  This  assessment  [step]  is 

ONLY  conducted  the  first  time  a  new 
developmental  product  is  “delivered”  for 
RITE  testing  and  integration.  For  any 
additional  drops,  CM  will  commence  at 
Step  4  upon  acceptance  of  delivery.) 

•  Reject;  notify  developer  and  specify 
issues  identified.  (Go  to  Step  8.) 

3 

QE  conducts  a  technology  baseline 
assessment  to  determine  the  current  (“as 
is”)  state  of  the  technology  being 
delivered.  Baseline  assessment  will  be 
conducted  using  the  Checklist  provided 
in  Appendix  B. 

•  Upon  completion,  notify  CM  to  execute 
build. 

4 

CM  builds  a  software-executable  version 
following  build  instructions  provided  in 
delivery  package. 

•  Accept  (build  successful):  Notify  QE 
(Step  5),  Security  Engineering  (Step  6), 
and  System  Integrator  (Step  7). 

•  Reject  (build  not  successful):  Notify 
developer  of  need  for  rework  (go  to 

Step  6). 

5 

QE  reviews  source  code  against 
requirements  of  the  QE  acceptance 
checklist. 

•  Accept;  go  to  Step  1 0. 

•  Reject;  notify  CM  with  reason  for 
rejection.  CM  go  to  Step  8.* 

6 

Security  Engineering  conducts  validation 
test  using  applicable  STIGs  and  runs 
relevant  automated  test  tools  (e.g.,  Gold 
Disc)  to  determine  IA  compliance  status. 

•  Accept;  go  to  Step  1 0. 

•  Reject;  notify  CM  with  reason  for 
rejection.  CM  go  to  Step  8.* 

7 

System  Integrator  reviews  delivery 
package  against  requirements  of  the 
Integration  acceptance  checklist. 

•  Accept;  go  to  Step  1 0. 

•  Reject;  notify  CM  with  reason  for 
rejection.  *  CM  go  to  Step  8. 

8 

CM  notifies  the  Program  Office  and 
Developer  of  rejection  and  provides 
reason  for  rejection. 

9 

Developer  reworks  software  work 
product  to  correct  problem(s)  with 
delivery. 

•  Upon  completion,  return  to  Step  4. 
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10 

If  accepted  by  QE,  Security,  and  System 
Integration,  CM  enters  executable  and 
delivery  package  contents  into  IR, 

establishing  initial  product  iteration 
baseline. 

Note.  ‘Rejection  by  Quality  Engineering  (Step  5)  and  Security  Engineering  (Step  6)  does  not 
automatically  delay  integration,  but  may  require  further  work  by  the  developer  to  complete  transition. 


Configuration  Management  and  Documentation 

The  documentation  identified  for  completion  as  part  of  the  C2RPC  prototype 
transition  is  developed  collaboratively  using  a  “confluence”  wiki.  For  the  development  of 
technical  reports,  confluence  combines  online  authoring  capabilities  and  tools.  Additionally, 
although  many  individuals  can  contribute  to  the  document  development,  the  Program  Office 
retains  complete  control  over  who  can  create,  edit,  and  view  and  export  documentation. 
During  the  prototype  development  and  transition  stages,  it  is  envisioned  that  different 
development  teams,  as  well  as  end-users  and  testing  teams,  will  be  asked  to  contribute  to 
the  respective  document  development.  Using  the  Wiki  ensures  that  contributors  are  using 
the  latest,  up-to-date  version  of  each  document  for  better  document  configuration  control. 
The  Wiki  also  allows  periodic  releases  of  the  documents  and  seamless  editing  as  the 
prototypes  evolve  as  part  of  the  transition  hardening  development. 

As  the  prototype  continues  to  mature,  required  documentation  is  completed  and  filed 
on  the  Wiki  for  use  by  stakeholders  in  performance  of  their  job  requirements.  The 
documents  listed  in  Figure  8  are  from  MIL-STD  498  Standards  (DoD,  n.d.),  whose  purpose 
is  to  establish  uniform  requirements  for  software  development  and  documentation.  The 
standard  and  its  Data  Item  Description  (DID)  are  meant  to  be  tailored  for  each  type  of 
software  to  which  they  are  applied.  Under  the  RITE  process,  SSC  Pac  works  with  the 
Program  Office  to  tailor  the  specific  standards  that  it  wants  to  invoke  for  each  specific 
contract.  The  POR  will  need  to  work  closely  with  the  C2RPC  to  produce  the  following  list  of 
documents  for  transition  to  the  MTC2. 

■  Software  Requirements  Specification  (SRS).  Specifies  the  requirements  for  a 
Computer  Software  Configuration  Item  (CSCI)  and  the  methods  to  be  used  to 
ensure  that  each  requirement  is  met. 

■  Software  Design  Description  (SDD).  Describes  the  design  of  CSCI-wide 
design  decisions,  the  CSCI  architectural  design,  and  the  detailed  design 
needed  to  implement  the  software. 

■  Software  Test  Description  (STD).  Describes  test  preparations,  test  cases, 
and  test  procedures  to  be  used  to  perform  qualification  (transition)  testing  of  a 
CSCI  or  software  system  or  subsystem. 

■  Software  Test  Plan  (STP).  Describes  the  plan  for  qualification  testing  of 
CSCI  and  software  systems.  Describes  the  test  environment  to  be  used  for 
testing,  identifies  tests  to  be  performed,  and  provides  the  schedule  for  test 
activities. 

■  Software  Transition  Plan  (STrP).  Identifies  the  hardware,  software,  and  other 
resources  needed  for  life  cycle  support  of  deliverable  software  and  describes 
the  developer’s  plans  for  transitioning  deliverable  items  to  the  support  agency 
(or  the  Acquirer). 


np si. 
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■  Software  Users  Manual  (SUM).  Explains  how  to  install  and  use  a  CSCI,  a 
group  of  related  CSCIs,  or  a  software  system  or  subsystem. 

■  Software  Versions  Description  (SVD).  Identifies  and  describes  a  software 
version  consisting  of  one  or  more  CSCIs.  It  is  used  to  release,  track,  and 
control  software  versions,  which  in  this  case  is  the  initial  software  release  for 
transition  to  the  POR. 


Summary 


The  C2PRC  is  an  initiative  jointly  funded  by  ONR  and  PEO  C4I  to  develop  new  C2 
capability  components  for  future  maritime  C2  PORs.  The  initiative  is  not  only  supporting  the 
implementation  of  a  new  C2  strategy  focused  around  the  four  functional  pillars  of  the 
Operational  Level  of  War  but  has  also  pioneered  new  prototype  development  and  transition 
processes  needed  to  rapidly  develop,  test,  and  field  new  software  technologies.  Uniting  the 
various  stakeholders,  the  C2RPC  has  streamlined  the  S&T  phases  of  the  acquisition 
process,  coupling  emerging  technology  requirements,  development,  testing,  and  integration 
phases  into  a  continuous  agile  software  development  model  designed  for  IT-intensive  C2 
systems. 

The  C2RPC  prototypes  have  undergone  an  intensive  development  and 
demonstration  process,  and  selected  components  are  expected  to  enter  transition  later  this 
year.  The  proof  will  be  in  the  ability  to  successfully  integrate  the  new  software  into  the  C2 
POR,  but  the  close  coordination  between  ONR  and  the  Program  Office  throughout  the 
prototype  development  has  reduced  POR  risk  and  should  allow  the  POR  to  field  the  new  C2 
software  earlier  than  would  have  been  possible  following  a  traditional  acquisition  cycle. 
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Introduction 


•  Navy  undergoing  C2  transformation  to  meet 
changing  mission  requirements 


•  2  Focus  Areas: 


>  New  C2  strategy 

-  based  upon  the  Operational  Level  of  War  (OLW) 

>  New  acquisition  methodology 

-  based  upon  incremental  component  capability  model 
providing  processes  for  rapid  and  agile  C2  software 
development,  test  and  integration  of  Science 
&Technology  (S&T)  into  Program  of  Record  (POR) 


Bringing  S&T  community  and  C2  acquisition  together 

as  one  continuous  program 
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Acquisition  Life  Cycle  Shortfalls 


DoD’s  S&T 
community  - 
2010  Budget 


Basic,  Applied  & 
Advanced  Research 

Advanced  Component 
Development  & 
Prototypes 

>$11  Billion 

>$14  Billion 

•  Studies* *  indicate  a  history  of  limited  DoD  success  in 
transitioning  S&T  investment  to  Programs  of  Record  (POR) 

•  Transition  Impediments  include: 

>  Lack  of  transition  funds  in  budget 

>  Transition  process  lacks  definition  and  visibility 

>  Different  goals  &  timelines  between  S&T  and  Acquisition  Mgrs 

>  Lack  of  incentives 

>  No  clear  guidance  during  development  from  POR 


*  National  Academy  of  Sciences,  The  Role  of  Experimentation  in  Building  Future  Naval  Forces,  http  ://w ww.nap.edu/catalog/1 1 125.html 

*  Naval  Research  Advisory  Council  (NRAC)  Technology  Acquisition  Reform,  March  2004 
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Bridging  the  Valley  of  Death 


d&c  *0% 

Transition 


S&T 

•  Continuum 

>  Organizational 

-  Relationships 

-  Cultural  Change 

-  Communication 

-  POR  Guidance 

>  Technical  Innovation 

>  Funding 


Valley  of  Death 


POR 

Implementation 

>  Processes 

-  Incremental  development 

-  Experimentation/Demos/LTEs 

-  Frequent,  early  &  automated 
testing 

>  Infrastructure 

-  Centralized  develop  repository 
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2  Rapid  Prototyping  Continuum  (C2RPC 

Migrating  to  Maturity 


Coalition  of  PEO  C4I,  ONR,  and 
COMPACFLT 


NR 


Rct'oliiUniiiiry  Research  .  .  .  Relevant  Results 


Develop  a  C2  Prototype  that  Feeds  Back  into  Enduring, 
Supported  Programs  Of  Record 

Accelerate  Development  of  OLW  C2  CONOPS 

>  COMPACFLT:  “Use  PACFLT  as  a  Petri  Dish 

>  Advance  the  State  of  the  Art  of  C2 


9  99 


-  Reduce  Uncertainty 
>  Ensure  Systems  Meet  Fleet  Prioritized  Capabilities/Needs 


Ensures  S&T  developed  capabilities  meet  needs  of  POR 


^Technology  Maturation  and  Funding 

Bridge 


Science  and  Technology 
Research  & 
Development 


Mission  Capability  Gap 
Identification  and 
Prioritization 


v 


Science  &  Technology 

War  Gaming 

Modeling  and  Simulation 

Map  to  operational  gaps 

TRL  1-2 

TRL  1-2 

/v 


S&T  Tush’ 

C2RPC 


POR  Tull’ 


Laboratory  Experimentation 
TRL  3-8 


Operational  Experimentation 
TRL  6-8 


Early  Stage 
(6.2/63) 


Late  Stage 
(63/6.4) 


MTC2 


Valley 
of  Death 


Program  of  Record 
TRL  8-9 


DT/OT  Process 


C2  Release 
Distribution 


Perceptions  of  S&T 
Community 


•  S&T’s  job  is  complete  at  the  tech  dev  stage 

•  Implementation  of  technology  is  the 
customer’s  responsibility 

•  “Role  of  S&T  is  tech  push-  build  it  and  they 
will  come” 

•  Develop  cycle  for  S&T  is  too  long  for  most 
acquisition  and  Warfighter  (Customers) 
•Lack  of  understanding  on  level  of  effort  to 
transition  technology 


Transition  Impediments 


•  Lack  of  transition  funds  in  budget 

•  Transition  process  lacks  definition  and  visibility 

•  Different  goals  &  timelines  between  S&T  and 
Acquisition  Mgrs 

•  Lack  of  incentives 

•No  clear  guidance  during  development  from  POR 


Notional  OLW  CONOPS 


usion 


Units, 

Capabil 

ities 


Intelligence  & 
Collection  Mgmt 
Pillar 


Intel 

“drill- 

downZ 


e.g.,  info  rqmt 
to  support 
task  or  decision 


Tasks 
“drill¬ 
down  ” 


ISR  Data 
Fusion 
Pillar 


Cross-Pillar 
Conditions  of  Interest 
Queries  &  Alerts 


e.g.,  ISR  capabm 
or  net  not  ready 


R/W/B 
tracks 
drill¬ 
down  ” 


e.g.,  unit  assigned  to 
task  is  not  ready 


Resources 
drill¬ 
down  ” 


Planning,  Execution 
&  Assessment 
Pillar 


Force,  Unit,  Network, 
Capabilities  &  Readiness 
Pillar 


Incremental  Functionality  Leads  to  C2  POR 


S&T  Prototyping  Continuum  -  Vision  to  Transition 


Drop  1 


Drop  3 


Drop  ‘N’ 


■2  ^ 
S-2 

M  co 
GC  S 
COU. 


Drop  2 


c 

0)0 
■|  3 

g  © 

■5.^ 

5m 


CO 

.s>  8 

S.c: 

II 


Apps 

support 

Data 

Mgmt 


Enterprise 

Services 

abstraction 


Baseline 


•  OTM 


•  R/W  Objects 
in  HaloCOP 


•  HaloCOP  Demo 
of  Task  Icons 


•  CPF  Readiness 
Pilot  (OPLAN 
Readiness) 

•  Multiple 
Readiness  Feeds 


•  HaloCOP, 
selected  data 
mgmt  services 


Drop  4 


Readiness  and 
MOC  Tools 

•Track  Mgmt 
Widgets  -  Initial 
Capability _ 

•  (13  Red  Force 
Objects  in  COP) 

•  I  POE  Assoc 
w/Plans 


•  Task  Navigator 
(Task  Drill-Down 
from  HaloCOP) 

•  Decision  Point, 
SOP  &  Cmd 
Relationships 

•  CPF  Readiness 
Pilot  (Priority 
Missions  Readi¬ 
ness)  w/PTDS 

•  Navy  Blue 

Canah/orns 

•  UFS  APIs  & 
WebTop 


Enhanced 
Readiness  and 
MOC  Tools 

•  White  Force 
Svc, 

•  Navy  Blue  Force 
mov’t  (WebSked), 
Environmental 
Qonelitions'fWx 

•  Targets 

•  IPOE  Integr’n 
with  Maritime 
COA  Sketch 


•  COA  Sketch, 
Line  of  Ops 
Tools  First  Look 

•  COA  Collabo¬ 
ration 


•  Additional 
Readiness 
Heuristics 

•  Additional 
Mission  Areas 


•  Collaborative 
COP  Initial 
Capability 

•  AIF  Prototype 


Multi-MOC 


Operations 


•  Navy  Blue  Force 
mov’t  (OTSR) 

•  OTM  Link  & 
Acoustic  Tracks 


•  Initial  Link  of 
CCIRs  to  Plans 
&  Decis  Points 


•  Maritime  COA 
Sketch/LOO  & 
Decision  Pts 

•  Ops  Sync  tool 
(Sync  Matrix) 

•  Distributed 
Planning  Among 
MOCs  &  TF/TGs 


•  Readiness 
Integrated 
with  Planning 
Processes  & 
Tools 


•  Initial  AIF 
Capability 
(Ashore,  Afloat) 

•  UFS  Process 
Workflow 
Support 


Capability 
cut-off  and 
transition 
to  C2  POR 


Dates  may  be  affected  by  CRA 


Drop  1 
(MARIO) 


Drop  2 
(SEP10) 


Drop  3* 
(MAY11) 


Drop  4* 
(DEC11) 


C2RPC  Incremental  Drops  to  C2  POR 


2011  2012  2014  2016 


C2  Rap  id 
Prototype 
Continuum 
(C2RPC) 


JCIDS 
"IT 
Box " 


Program 

Of 

Record 


MAR  SEP  MAY  .  . 

2010  2010  2011  L  I  j\ 

MOC 


\  TF/TG 


PMW-1 50/ONR-Funded  Prototyping 

I _ ,1 _ I _ I _ 


/  Unit  ss 


2  3 


|^\ 

qP  Ns  qP  \ 

PMW-1 50  architecture^  ^ 


e  ✓!  >  S&T  INTEGRATION  anil  TRANSITION  to  POR  > 

<(/  /  \  <</  /  <o  '  1  A  / 

S  S'  S/  \  J?/ 


:  ■ :  ■ z:.\n _  , 

!  Expand  and  harden  capabilities  fo,  MOC  and  \ 

!  below  C2  on  Navy  GCCS-M  platforms  &  sites  / 
- 1  |  -\r r^- 


GCCS-M 


MTC2 


9 


Rapid  Integration  and  Testing  Environment 

‘Four  Pillars’ 


RITE  addresses 
findings  and 
facilitates 
development  and 
distribution  of  Navy 
C2  systems: 


▼  Check  -software 
development 

▼  Stabilize -the 
current  build 

▼  Influence  -  the 
final  product 
delivery 


“Manage  as  close 
to  the  source,  as 
possible ” 


/ 


\ 


:  RITE  PILLARS 


w 

o 

<0 


o 

o 


•Govt 

responsible  for 
non-functional 
‘requirements 
definition 

•“Govt  Purpose 
Rights”  or 
“unlimited 
Rights”  for  s/w 
(include  source 
code) 

•Drives 

CDRLs/DIDs/C 

PARS 

deliverables 

•Aligns 
Developers 
and  Testers 


•  Puts  increased 
effort  into  early 

52  stages  of  PLC 

</) 

<D  •  Integrates  “early” 
O  and  “frequent” 

O  testing  into 

^  Development 
Q-  stage 

•  Requires  regular 
engineering  drops 
of  software 

•  Institutionalize 
source  code 
analysis 

•Automates  and 
focuses  testing 

•Standardizes  tools 
and  test  cases  for 
Developers  and 
Testers 


\ 


S 


•Centralized 
Repository- 
enhances  project 
communication 
and  collaboration 


■K  •  Create  Framework 
<2  for: 

(B 

^  •  Software 

^  Distribution/Apps 

—  Store 


•  Documentation 
Library 

•  Development 

•Software  Testing 
tools  and  data 


•Centralized 

software 

Configuration 

Management 


1  c 

1  o 

•Establish 

Governance  Plan 

03 

.N 

based  upon 

community 

process 

1  C 

1  <0 

•  Rebuilds  Govt  in- 

1  S? 

house  S/W  SME’s 

to  LEAD  and 

i  o 

WORK  “as  Deers” 

1 

with  Private 

1 

1 

Industry 

1 

•  Establishes  S/W 

1 

career  pipeline 
(Software  focused 

1 

vs.  operationally 

1 

1 

1 

1 

1 

1 

focused) 

/ 

/ 


/ 
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IT  Acquisition  Life  Cycle 

Bridge 


C2POR 


O  Materiel 
Development 
Decision 


IOT&E 


Nat ’l  Defense 
Authorization 
Act  2010 


RITE  Life  Cycle 
(, SSA ) 


Supports  all  Phases  of 
New  IT  Acquisition 


Rapid  Integration  and  Testing  Environment  (RITE) 


RITE  Supports  Technology  Maturation 


S&T 


Valley  C 2  POR 

of  Death 


Add9 1  New  Releases 


Subset  -New  POR  Release 


Capability  Drops 
#1  thru  #  “N”  (Iterative 
Process) 


Component  Prototype 
Demonstrated  in 
Relevant 
Environment 


Component 
Validation  in 
Laboratory 
Environment 


Component 
Validation  in 
Relevant 
Environment 


I  CDDs  Capabilities  Development  Document 

j  CDP  Capabilities  Development  Plan 


RITE  POR  Transition 
Support 


Milestone  Build 
Decision 


B/C 


CDD 


CDP 


C2RPC  (S&T) 

(Pre-Milestone  B) 

Technology  Development  and  Demonstration 
Prototypes  mature  towards  transition 
(TRL4-6) 


MDD 

(Milestone) 

A 


- - 

"^1 

Pre-Delivery 

SCA  and 

Quals 

— 

CM 

~ 

Funct  Test 

- 

QA/QE 

- 

IV&V 

4 

1 

L 

Integration 

(Auto)Test 


INCREMENT  CAPABILITY  TRANSITION 

( Centralized  Repository  -  Progressive  Integration ) 


RITE’S  Iterative  Development  Process 


e 


Segment  gets  returned  to 
developer  for  rework  on  failures 


Developer  completed  “private  build,” 
automated  unit  tests,  automated  inspections 


•  Software  works  together  ? 

•  Software  works  as  intended  ? 

•  Adhering  to  established  stds? 

•  Code  covered  adequately  ? 

•  Test  results? 

•  Meets  requirements  ? 


eveloper  has  a  segment  ready: 

Completed  UNIT  testing 
NESI  compliance  checks 


o 


Build  and  test  results  e-mailed 
to  team 


SSC  Version  (CM) 
Control  Repository 


A  segment  that’s  committed,  triggers  an 
integration  build  as  SSC 

Tests  are  added  as  code  gets  integrated 


O 

Just-in-time  Build  status  and  quality  metrics 
Build  success/failure,  quality,  etc.  trends 


Automated  code  Inspection  tools 

•  code  complexity 

•  code  duplication 

•  architectural  layering 

•  coding  standards 

•  duplicate  code 

•  Coverage 


Accumulated  Test  suites  library 

1  Developer  tests 
1  Component/subsystem  tests 
1  System  tests 
1  Operational  tests 
1  regression  tests 
1  functional  tests 
1  Integration  tests 


Summary 


•  C2RPC  is  an  ONR  and  PEO  C4I  Partnership  to  bring  new  technology  to  the 
warfighter 


>  Provides  insertion  path  for  POR  expectation  and  guidance  to  S&T  prototyping 

>  Coordinates  various  funding  sources  to  bridge  the  valley  of  death 

>  Supports  open  communication  between  all  stakeholders 

>  Establishes  continuous  interaction  with  Fleet  to  understand  operational  needs 
and  validate  prototype  solutions 

>  Accelerates  the  transition  of  User-Validated  C2  capabilities  into  POR 


•  RITE  provides  assured  integration  of  the  technologies  to  meet  cost, 
schedule  &  performance 


>  C2RPC  is  the  first,  from  the  ground  up,  services  architecture  application 
designed  to  run  on  a  shore  based  "cloud"  infrastructure  or  from  new 
Consolidated  Afloat  Network  Enterprise  Services  (CANES)  infrastructure. 


>  Establishes  C2  autonomous  afloat  capability  (when  needed)  AND  ashore  high 
performance  computer  and  network  infrastructure  augmentation  when  available 
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Back-up 


C2RPC  Governance 


•  Governance 

>  Workshops 

-  Used  to  establish  operational  objectives  and  receive  operator  feedback 

-  2  to  3  day  workshops  held  at  COMPACFLT  (held  quarterly) 

>  Tech  Reps 

-  Assigned  full-time  (embedded)  SME  as  “liaison”  at  COMPACFLT  to  gather  real¬ 
time  feedback  for  possible  development  modification 

>  Software  Change  Requests  (SCRs) 

-  Formal  process  of  submitting/documenting  through  trouble  tickets 

-  Used  by  ERB  to  document  longer-range  version  enhancements,  reprioritize 
current  development  efforts  and  assign  resources 

>  ERB 

-  Governing  body  consisting  of  reps  from  ONR,  PMW-150,  &  development 
contractors 

-  Chaired  by  C2RPC  Chief  Engineer 

-  Meets  “weekly”  to  review 
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Capabilities/Requirements 

Development 


ONR  (4) 


-non-mature 
Requirements  and 
Gaps 


-emerging  technologies 
And  new  capabilities  for 
Evaluation  and  transition 


New  Technology 
Phase 


S  SC/Contractor 
(6) 

-Provide  Prototype 
Technology 

-Develop  Prototype 
Technology 

w 

Fleet  Collaboration 
Team  (2) 


-Evaluate/prioritize  needs 
into  Requirement 


NNWC  (3) 

^  Provide  Requirements 

-FOR  type 


ReqniremenK 


-Requirements  not 
Technically  mature 


-Emerging  Technology 


-IA  certification 


Fleet  User  flat 


-Provide  Needs  and 
Capability  requests. 


-Use 

Technology 


-Evaluate  usability  of 
system  and 
provide  feedback 


-Determine 

Needs 


X 


Centers  Of  Excellence 

-Determine 

(lb) 

-Provide  Needs 


Needs 


and 

Capability 

requests. 


-Evaluate  usability 

of  system 
and  provide 
feedback 


Requirements  Phase 


Legend 


Approved  Process  -  one  way 
Approved  Process  -  two  way 

Not  part  of  the  process  but 
currently  happens  -  one  way 

Not  part  of  the  process  but 
currently  happens  -  two  way 


Requirements  Phase 
New  Technology  Phase 
Development  &  Production  Phase 


N  Codes  (5) 


-Provide  Prioritization 
and  Funding  for 
Requirements 

-Co-sign  TTAs 


Development  & 
Production  Phase 


PMWs  (7) 


-Provide  Development, 
Implementation, 
Transition,  and 
Sustainment 

of  Tech  nolo  cry 


-Provide  Guidance 
and  Oversight 
for  development 


SSC/SSA  (8) 


-Perform  SSA  Functions 


-Evaluate  usability  of 
system  and  provide 
feedback 


-  Support  Technology 
Transition 


COMOPTEVFOR  (9) 

Provide  Operational  Test  and 
Evaluation 
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RITE’S 

Agile  Integration  and  Test  Architecture 


Transition  Testing 


Requirements  Process 


•  Current  process  does  not  meet  rapid  and  agile 
development  requirements  -  too  cumbersome  and  slow 

>  April  201 1  -  vice  chairman  Joint  Chiefs  of  Staff  announced  DoD 
plans  to  rewrite  acquisition  requirements  process  (JCIDS) 

>  No  clear  feedback  functionality  within  the  process  to  assure 
development  is  correct 

•  C2RPC  uses  a  modified  ‘operational  objectives’  collection 
process 

>  Links  S&T  community  with  Acquisition  Manager 

>  Involves  interaction  between  Fleet  operators  and  prototype 
developers 
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